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Abstract: 

The  DoD  Architecture  Eramework  is  now  popularly  used  for  describing  overall 
requirements  and  architectural  design  of  the  system-of-systems  (SoS).  However,  it  is  very  hard 
to  validate  and  verify  the  architecture  products,  as  most  of  them  are  modeled  with  informal 
constructs.  The  paper  proposes  an  approach  of  executable  architecture  modeling  and  simulation 
by  introducing  formal  UME  specification.  Eirstly,  definitions  of  executable  architecture  are 
provided,  upon  which  both  structural  and  behavioral  meta-models  of  SoS  architecture  are  built 
by  extending  fUME  meta  models.  Then,  a  simulation  language  is  defined  based  on  Process 
Algebras,  and  the  semantics  of  emergent  behavior  of  SoS  is  discussed.  The  executable  models  of 
a  SoS  architecture  are  therefore  constructed  through:  (1)  modeling  the  structures  and  behaviors 
of  SoS,  (2)  translating  the  models  into  process  terms  and  (3)  specifying  simulation  rules  upon  the 
process  terms.  Since  Process  Algebras  based  executable  tools  are  available  over  relevant  research 
institutions,  it  is  not  difficult  to  build  a  simulation  execution  environment.  Einally,  a  case  study  is 
used  to  illustrate  the  feasibility  of  the  approach. 
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1.  Introduction 

Architecture  describes  the  components  of  system,  connectors  between  these  components,  rules 
which  are  used  to  guide  the  design  and  evolvement  of  system.  It  is  a  blueprint  of  system  and 
bridges  the  gap  between  requirements  and  implements  in  the  design  of  system-of-systems  (SoS). 
The  quality  of  architecture  can  influence  the  schedule  of  SoS  designment  and  the  quality  of  SoS. 
So  in  the  early  development  of  architecture,  using  modeling  and  simulation  to  analyze  and 
demonstrate  is  particularly  important  [1]. 

The  DoD  Architecture  Eramework  is  now  popularly  used  for  describing  overall  requirements 
and  architectural  design  of  SoS  [2].  However,  it  is  very  hard  to  validate  and  verify  the 
architecture  products,  as  most  of  them  are  modeled  with  informal  constructs.  These  models 
cannot  be  executed  before  being  translated  into  an  formal  language,  such  as  Petri  Net.  And,  the 


Report  Documentation  Page 


Form  Approved 
0MB  No.  0704-0188 


Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 
VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  0MB  control  number. 


1.  REPORT  DATE 

JUN  2014 


2.  REPORT  TYPE 


3.  DATES  COVERED 

00-00-2014  to  00-00-2014 


4.  TITLE  AND  SUBTITLE 

Executable  Architecture  Modeling  and  Simulation  Based  on  fUML 


6.  AUTHOR(S) 


7.  PEREORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

PLA  University  of  Science  and  Technology, Nanjing,  China, 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 


5a.  CONTRACT  NUMBER 


5b.  GRANT  NUMBER 

5c.  PROGRAM  ELEMENT  NUMBER 

5d.  PROJECT  NUMBER 


5e.  TASK  NUMBER 


5f.  WORK  UNIT  NUMBER 

8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 


10.  SPONSOR/MONITOR’S  ACRONYM(S) 

11.  SPONSOR/MONITOR’S  REPORT 
NUMBER(S) 


12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 


13.  SUPPLEMENTARY  NOTES 

Presented  at  the  18th  International  Command  &  Control  Research  &  Technology  Symposium  (ICCRTS) 
held  16-19  June,  2014  in  Alexandria,  VA.  U.S.  Government  or  Federal  Rights  License 

14.  ABSTRACT 


15.  SUBJECT  TERMS 

16.  SECURITY  CLASSIFICATION  OF: 


a.  REPORT 

unclassified 


b.  ABSTRACT 

unclassified 


c.  THIS  PAGE 

unclassified 


17.  LIMITATION  OF 

18.  NUMBER 

ABSTRACT 

OE  PAGES 

Same  as 

17 

Report  (SAR) 

19a.  NAME  OE 
RESPONSIBLE  PERSON 


Standard  Form  298  (Rev.  8-98} 

Prescribed  by  ANSI  Std  Z39-18 


translation  might  be  a  pain  of  system  engineers  due  to  their  weakness  in  formal  languages.  They 
would  hope  that  the  architeetual  models  they  built  be  automatieally  translated  into  exeeutable 
ones. 

UML  is  accepted  as  an  Architectural  Description  Language  by  architects,  and  it  has  become  a 
standard  notation  to  document  the  architecture  of  system  [3].  To  describe  the  dynamic  behaviors 
of  system,  UML2.0  enriches  the  behavioral  semantics  by  adding  the  detailed  action  semantics 
[4].  But  these  UML  models  are  not  executable.  Object  Management  Group  proposes  the  fUML 
to  enable  UML  models  execution  [5].  Accordingly,  we  propose  an  approach  of  executable 
architecture  modeling  and  simulation  by  introducing  fUML  specification.  Firstly,  we  construct 
the  meta-models  for  structural  and  behavioral  models  of  SoS  architecture  by  extending  fUML. 
To  enable  execution,  we  introduce  the  concrete  syntax  and  algebra  semantics  for  the  SoS 
architecture  models,  and  the  execution  processes  can  be  interpreted  as  run  of  algebra  derivation. 
Finally,  we  use  the  process  trace  to  exhibit  the  emergent  behavior  of  SoS. 

The  rest  of  the  paper  is  organized  as  follows.  Section  2  describes  the  related  research.  Section 
3  introduces  the  executable  architecture.  Section  4  describes  the  formalization  of  behavioral 
model.  Section  5  proposes  the  behavioral  analysis  for  SoS  architecture.  Section  6  uses  a  case 
study  to  demonstrate  the  availability  of  the  theory. 

2.  Related  Work 

Architecture  verification  plays  an  important  role  in  design  of  SoS.  The  current  verification 
techniques  based  on  model  execution  can  be  classified  into  two  categories:  executable 
architecture  modeling  and  model  transformation.  The  former  requires  that  the  architecture  be 
modeled  as  executable  models  or  executable  rules  be  defined.  The  latter  implies  translation  of 
the  architecture  models  into  executable  ones,  such  as  Petri  Net,  Extends im  model,  DEVS. 

The  MITRE  Company  proposes  a  method  for  executable  architecture  modeling.  The  business 
process  models,  communication  models  and  campaign  simulation  environment  are  connected  by 
the  Runtime  Infrastructure  of  High  Eevel  Architecture [6].  Jiang  et  al.  [7]  define  the  concepts  and 
executable  rules  for  executable  architecture  and  hence  make  some  products  of  DoD  architecture 
executable.  Wang  et  al.  [8]  develop  an  executable  architecture  based  on  SOA.  But  these 
executable  models  pay  much  attention  to  the  details  of  systems  and  therefore  need  great  efforts. 
So,  there  is  an  argue  about  whether  the  executable  architecture  is  needed. 

As  most  behavioral  models  of  architecture  are  not  executable,  they  need  to  be  translated  into 
some  executable  ones.  Petri  Net  is  a  popular  executable  modeling  language  for  SoS  behaviors. 
Wang  et  al.[9]  use  SysME  sequence  diagram  to  model  the  behaviors  and  translate  the  models 
into  Colored  Petri  Nets  (CPN).  Staines  T.S  [10]  incorporate  fundamental  CPN  concepts  into 
UME  activity  models  such  that  the  behavioral  models  are  therefore  formalized  with  executable 
sementics.  Jiang  et  al.  [11]  use  Object  Petri  Nets  to  formalize  the  IDEP3  models  which  describe 
system  processes.  Ge  et  al[12].  translate  the  UME  models  of  architecture  products  into 
ExtendSim  model.  Touraille  et  al.[13]  integrate  single  platform  tools  for  modeling,  simulation, 
analysis  and  collaboration,  and  then  develop  SimStudio  which  is  a  modeling  and  simulation 
environment  based  on  the  Discrete  Event  Systems  Specification  (DEVS)  formalism.  Based  on 


DEVS,  Kara  et  al.[14]  also  propose  a  Simulation  Modeling  Architecture  (SiMA).  SiMA  supports 
hierarchical  and  modular  composition  of  reusable  models.  Combining  DEVS  and  MDD, 
Cetinkaya  et  al.[15]  develop  a  MDD  framework  for  modeling  and  simulation 
(MDD4MS). COMPASS  (Comprehensive  Modeling  for  Advanced  Systems  of  Systems)  project 
develops  a  formal  language  (COMPASS  Modeling  Eanguage,  CME)  for  modeling  and  analyzing 
SoS[16].  CME  is  based  on  VDM,  CSP  and  Circus.  The  process  algebraic  combinators  are  used 
to  describe  the  behavior  of  SoS.  The  analysis  techniques  and  prototype  tools  for  UME  are  still  in 
the  development  process. 

But  a  few  of  the  above  approaches  take  into  consideration  the  emergence  behavior  of  SoS. 
Our  approach  translates  the  behavoral  model  into  the  process  items  of  Process  Algebras,  and  use 
the  process  trace  to  exhibit  the  emergence  behavior  of  SoS. 

3.  Executable  Architecture 

The  executable  architecture  is  made  up  of  three  parts:  the  executable  model,  the  execution 
mechanism  and  the  execution  process.  The  executable  model,  the  fundation  for  the  executable 
architecture,  comprises  both  static  and  action  models.  The  mechansim  describes  the  execution 
principle  of  dynamic  models.  The  execution  process  describes  the  process  of  model  execution. 
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Fig.  1 .  The  Executable  Architecture 

3.1  Meta  Model  of  SoS  Structure 

The  meta  model  of  SoS  structure  extends  the  Class  Model  of.  The  system  engineers  use 
structure  models  to  describe  the  structure  of  SoS,  environment  object  and  windows  of  simulator. 

Structure  of  SoS 

System  is  a  core  concept  of  the  structure  models.  These  systems  and  their  relationships  make 
up  of  the  structure  of  SoS.  To  simulate  the  behaviors  of  SoS,  the  relationships  can  be  abstracted 
as  data  flow.  Systems  are  connected  with  each  other  through  data  flow.  The  output  data  of  one 
system  is  the  input  data  of  another.  A  couple  of  output  and  input  data  makes  up  of  a  data  flow. 
Systems  use  ports  as  interface  to  send  and  receive  data.  The  data  is  information  produced  by 
activities.  The  activities  are  performed  by  systems  which  access  data  through  their  port. 

Environment  Object 

There  are  two  kinds  of  environment  object.  One  is  Data,  the  other  is  Event.  Data  can  either  be 
produced  in  SoS  simulation  or  be  given  (input)  by  engineers.  They  can  be  input  from  or  output  to 
the  windows  of  simulator.  Event  can  take  place  inside  or  outside  of  SoS.  It  is  used  to  trigger 
activity  and  change  the  execution  process  of  activity.  Time  is  a  special  event  which  is 
automatically  triggered  at  a  time.  It  is  defined  by  the  simulator  of  SoS.  The  simulator  can 
monitor  the  changes  of  environment  object  according  to  the  time.  Time  can  also  trigger  activity 
and  change  the  execution  process. 


Windows  of  Simulator 


Windows  of  Simulator  are  the  interfaces  with  which  engineers  can  observe  the  changes  of  the 
environment  and  control  the  execution  process.  The  simulator  privides  different  windows  for 
data,  event  and  time.  During  the  simulation,  engineers  play  the  role  of  Organizations.  They  use 
these  windows  to  interact  with  SoS.  They  send  inputs  through  the  windows  to  simulator  to 
control  the  execution  process  and  receive  the  output  from  the  windows  to  observe  the  SoS 
behaviors  and  their  effects. 


di  splays 


Fig.  2.  The  meta  model  of  SoS  structure 

3.2  Meta  Model  of  SoS  Behaviors 

We  choose  activity  diagram  to  describe  the  behavior  of  SoS,  because  the  simulation  of  SoS 
behaviors  is  processed  as  sequences  of  activities.  The  meta  model  of  behaviors  extends  the  meta 
model  of  Activity  Diagram  of  fUML  and  is  shown  in  Fig.  3. 

The  SoS  behaviors  are  modeled  with  notations,  such  as  Activity,  NoActionActivity, 
Transition,  GuardCondition,  Action,  Swimlane,  Start  and  End.  Action  is  the  fundamental  unit. 
An  activity  encapsulates  a  number  of  actions  and  is  the  execution  body  of  the  containing  actions. 
NoActionActivity  is  a  kind  of  control  activity  containing  no  action.  It  can  be  classified  into 
Decision,  Fork  and  Join.  The  notations  are  slightly  different  from  fUML  in  followings. 

(1)  Action  is  the  only  executable  unit.  It  can  be  either  SysDefAction  or  UserDef Action. 
SysDef Action  is  the  executable  units  pre-defined  by  simulator,  and  UserDef  Action  is  the 
user-defined  executable  units  programmed  by  engineers. 

(2)  Swimlane  is  the  bridge  between  Activity  and  Data.  It  represents  constituent  systems  that 
perform  activities  and  provide  the  data  ports  through  which  activities  access  and  modify 
the  data  as  Input  or  Output. 

The  semantics  of  other  notations  is  the  same  as  fUML,  except  following  constraints  that 
guarantee  the  model  robustness. 

(1)  There  should  be  a  sole  pair  of  Start  and  End  in  the  behavioral  model. 


(2)  No  any  notation  object  except  Activity  contains  an  event  or  action. 

(3)  Assume  the  transition  that  flows  to  an  activity  is  In-Transition,  and  the  one  that  flows  from 
an  activity  is  Out-Transition.  Each  activity  should  have  only  one  In-Transition  and  one 
Out-Transition. 

(4)  Each  swimlane  should  represent  one  constituent  system.  There  should  not  be  two  different 
swimlanes  which  represent  a  same  constituent  system. 


Fig.  3.  The  behavioral  meta  model  of  SoS 

3.3  Executable  Semantics  of  Models 

To  simulate  the  SoS,  the  mechanism  and  executable  semantics  must  be  defined.  The  structure 
models  of  SoS  define  the  structure  of  systems  and  the  types  of  data  which  are  classified  as  Input 
or  Output.  The  behavioral  models  of  SoS  define  activities  to  simulate  the  behaviors  of  SoS. 
During  the  simulation,  the  simulator  interprets  the  behavioral  models  and  transform  them  into  an 
executable  language  which  will  be  discussed  in  Section  4. 

The  simulator  is  a  multithreading  system.  It  controls  the  execution  of  behavioral  models.  Once 
a  SoS  simulation  is  started,  the  simulator  runs  the  SimulationMain  and  load  the  behavioral 
model.  SimulationMain  is  the  main  thread  of  simulation.  The  simulator,  while  interpreting  the 
behavioral  model,  creates  a  number  of  SimulationProcs  to  execute  activities.  It  receives  the 
instructions  and  data  from  its  observation  windows,  and  sends  them  to  the  SimulationProcs.  If  an 
activity  has  been  executed,  the  SimulationProc  is  killed. 

The  executable  semantics  of  models  is  described  in  Pig.  4.  Each  activity,  including 
NoActionActivity,  is  executed  in  a  SimulationProc.  The  Start  creates  a  SimulationProc  to 
execute  the  first  activity.  The  End  creates  a  SimulationProc  to  send  an  event  to  terminate  the 
simulation.  The  Decision  creates  a  Deciding  SimulationProc  to  set  the  decision  result  which 
affects  the  conditions  of  its  Out-Transitions  and  creates  a  SimulationProc  for  the  subsequent 
activity  whose  In-Transition  condition  is  satisfied.  Pork  creates  a  SimulationProc  for  every 


subsequent  activity  whose  In-Transition  connects  with  it.  Join  creates  a  Waiting  SimulationProc 
which  waits  for  all  SimulationProcs  of  the  Fork  activities  being  terminated  and  then  creates  a 
SimulationProc  for  the  activity  whose  In-Transition  connects  with  Join. 


Fig.  4.  The  executable  semantics  of  SoSEM 

4.  Formalization  of  Behavioral  Model 

Formalization  is  fundamental  for  the  models  to  be  executable.  This  section  will  focus  on 
building  the  concrete  syntax,  algebra  semantics  and  executable  rules  for  the  executable 
behavioral  model  (EBM)  of  SoS. 

4.1  Concrete  Syntax 

Since  activities  are  performed  by  systems,  each  of  them  should  belong  to  an  operator  which  is 
visually  presented  as  a  swimlane.  Actions  are  encapsulated  in  the  activities.  The 
NoActionActivity  and  Transition  control  the  execution  sequence  of  activities.  The  Input  and 
Output  supply  the  information  for  execution  of  activities.  The  concrete  syntax  of  EBM  is 
thereafter  defined  with  Backus-Naur  Eorm  (BNE),  and  is  shown  in  table  1  where  the  terminators 
are  highlighted  in  bold  font. 

Table  1  The  concrete  syntax  of  EBM 

<activity  model>  ::=  activitymodel  <model  name>;<operator  list>;<control  list>  end 

activitymodel 

<operator  list>  ::=  <operator><operator  list>l<> 

<operator  >  ::=  operator  <operator  namexactivity  list>  end  operator 
<activity  list>  ::=  <activity><activity  list>l<> 

<activity>  : :  =  { <input> }  <action>  { <output> } 

<input>  ::=  in  <messageld>  from  <operator  name> 

<output>  ::=  out  <messageld>  to  <operator  name> 


<action>  ::=  action  <action  name>{<precondition>}{<guard  condition>}{<post  condition>} 

end  action 

<precondition>  ::=  pre  <condition> 

<guard  condition>  ::=  guard<condition> 

<post  condition>::=  post<condition> 

<condition>  ::=  <expi> 

<control  list>  ::=  <control><control  list>l<> 

<control>  ::=  <fork>l<join>l<decision>l<transition> 

<transition>  ::=  transition  <source>{<condition>}<target>  end  transition 
<fork>::=  fork  <source><target  list>  end  fork 
<join>  ::=  join<source  list><target>  end  join 

<decision>  ::=  decision  <source><condition><target><target>  end  decision 
<source  list>  ::=  <source><source  list>l<> 

<target  list>  ::=  <target><target  list>l<> 

<source>  ::=  source  <operator  namexaction  name>  end  source 
<target>  ::=  target  <operator  namexaction  name>  end  target 


4.2  Algebra  Semantics 

The  execution  of  the  EBM  can  be  abstracted  as  running  processes.  Every  activity  or  its 
containing  action  may  take  a  process.  An  activity,  when  being  performed  by  a  system  on  the 
Input  or  Output  data  objects,  would  initiate  one  process  for  each  containing  action  which  is 
considered  to  be  operated  by  the  system.  Therefore,  an  atomic  process  can  be  abstracted  as  a  pair 
of  operator  and  action.  To  formalize  the  EBM,  we  define  an  Algebras  Process  based  language, 
the  executable  activity  algebras  (EAA),  to  explain  the  process  semantics. 

Definition  1.  Assume  O  is  the  set  of  operators  (or  systems)  ando  g  0  ;  A  is  the  set  of  actions 
andae  A;  P  denotes  the  process.  The  syntax  of  EAA  can  be  thereafter  defined  with  BNE  as 
follows: 


p 


0  I  (o,  a).P  \P^-,P^\P^+^PJ[<  expr  >]^>  I 
P,\\P,\P,KP, 


,  where: 


•  O(Empty):  0  is  an  empty  process; 

•  (o,  a).P (Prefix):  P  becomes  active  when  a  has  been  executed  by  o; 


•  P;,P^  (Sequence):  P2  becomes  active  when  Pi  has  been  executed; 

•  ^  ^2  (Choice):  if  c  is  true  then  Pi  becomes  active;  otherwise,  P2  becomes  active; 

•  [<  expr>]P  (Condition):  if  <expr>  is  true  then  P  becomes  active;  otherwise,  P  is  suspended; 


P^\\P2  (Pork):  Pi  and  P2  are  executed  concurrently; 


lip  (Join):  P  becomes  active  when  the  two  concurrent  processes  Pi  and  P2  have  all 


finished  their  execution. 

The  EAA  provides  a  domain  of  process  algebras  semantics  for  the  EBM,  or  the  process 
algebras  semantics  of  EBM  is  an  instance  of  EAA.  Accordingly,  we  can  translate  the  models  of 
EBM  into  terms  of  EAA  by  building  mappings  between  the  syntax  of  EBM  and  EAA. 

Eollowings  introduce  functions  for  mappings  of  the  main  productions  of  the  concrete  syntax. 
Assume  the  simulator  interprets  EBM  by  bottom-up  compilation,  and  if  the  <string>  is  a 
non-terminator  of  the  concrete  syntax  of  EBM,  then  the  function  //(<string>)  gives  the  set  of  all 
possible  terminators  from  which  the  non-terminator  <string>  can  be  deduced. 

Definition  2.  The  semantic  functions  for  mapping  of  source  or  target  are  defined  as : 

Saci<  source  >)  =  (//(<  operator  name  >),  H{<  action  name  >)) 

S^^i<  target  >)  =  {H{<  operator  name  >),  H(<  action  name  >)) 

Definition  3.  The  semantic  functions  for  mapping  of  target  list  are  defined  as: 

S(<  target  list  >)  =  S^^{<  target^  >)  II  S^^{<  target^  >), 

V  <  target ^  >,  <  target^  >e<  target  list  > 

Definition  4.  The  semantic  functions  for  mapping  of  fork  are  defined  as : 

S fg{<  fork  >)  =  S^^{<  source  >);S(<  target  list  >), 

<  source  >,<  target  list  >e<  fork  > 

Definition  5.  The  semantic  function  for  mapping  of  join  is  defined  as: 

Sj„{<  join  >)  =  S^^{<  source^  >)  \\s^^(^,arget»  source^  >), 

V  <  source^  >,<  source^  >e<  source  list  >,<  source  list  >,<  target  >e<  join  > 

Definition  6.  The  semantics  function  for  mapping  of  decision  is  defined  as : 

Sdei<  decision  >)  =  S^^{<  source  >); S^{<  target^  >)  target ^  >) 

Definition  7.  The  semantics  function  for  mapping  of  transition  is  defined  as : 

Sjr\i<  transition  >)  =  S^{<  source  >);[//(<  condition  >)]S^^i<  target  >),<  condition  f 

or  (<  transition  >)  =  (<  source  >);  (<  target  >) 

Definition  8.  The  semantic  function  for  mapping  of  operators  is  defined  as : 

(<  operator  >)  =  {(//(<  operator  name  >),//(<  action  name  >)) 

I  V  <  action  >e<  activity  list  >,  <  activity  list  >e<  operator  >} 

Basing  on  above  functions,  we  provide  the  algorithm  of  transforming  the  model  of  EBM  into 
the  process  terms  of  EAA. 

Input:  the  whole  deduction  stack  of  EBM  model 
Output:  the  set  of  process  terms  of  EAA  P 


Procedure 

Step  1:  create  an  empty  set  P  to  express  the  algebra  model  of  EBM; 

Step  2:  for  every  <operator>  of  <operator  list>,  invoke  the  semantic  function  SopO  to 
generate  the  atomic  processes,  (//(<operator  name>,  //(<action  name>)),  and  add  them  to 
the  set  P. 

Step  3:  for  every  <transition>  in  the  <control  list>,  invoke  S;w(),  if  <condition>  =null,  or 
StriO  to  generate  complex  process  terms  and  add  them  to  the  set  P. 

Step  4:  for  every  <fork>  in  the  <control  list>,  invoke  S/oO  to  generate  complex  process  terms 
and  add  them  to  the  set  P. 

Step  5:  for  every  <join>  in  the  <control  list>,  invoke  SjoO  to  generate  complex  process  terms 
and  add  them  to  the  set  P. 

Step  6:  for  every  <decision>  in  the  <control  list>,  invoke  SdeO  to  generate  complex  process 
terms  and  add  them  to  the  set  P. 

Step  7 :  output  the  set  of  process  terms  P. 

4.3  Executable  Rules 

The  simulation  of  SoS  behaviors  is  driven  by  a  set  of  derivation  rules  applied  for  evolution  of 
process  algebra.  To  support  the  evolution,  we  define  the  rule  set  as  follows. 

Prefix  Rule 


Rule  Action-1  shows  that  process  0  will  become  active  when  the  process  (o,a)  is  active  and  a 
has  been  executed  by  o.  Rule  Action-2  shows  that  process  P  will  become  active  when  the  process 
(o,a).P  is  active  and  a  has  been  executed  by  o.  □  denotes  that  precondition  of  the  rules  is 
always  true. 

Sequence  Rule 


Rule  Sequence  shows  that  if  the  process  Pj  can  be  activated  by  the  process  Pj  when  a  has 
been  executed  by  o,  the  process  will  activate  the  process  P^^P^  when  o  has  executed  a. 


Choice  Rule 


Rule  Choice-1  shows  that  if  condition  c  is  true,  activates  P^  .  Rule  Choice-2  shows 

that  if  condition  c  is  false,  P^  P^  activates  P^  .  Rule  Choice-3  shows  that  if  P^  activates  Pj 

when  a  has  been  executed  by  o,  p^+^p  activates  Pj  when  a  has  been  executed  by  o.  Rule 

Choice-4  shows  that  if  P^  activates  P^  when  a  has  been  executed  by  o,  P^  P^  activates  P^ 
when  a  has  been  executed  by  o. 

Condition  Rule 


Rule  Condition-1  shows  that  if  the  condition  [x=y]  is  true,  [x=y]P  activates  P.  Rule 
Condition-2  shows  that  if  the  condition  [x=y]  is  false,  [x=y]P  activates  0.  □  denotes  that 
precondition  of  the  rules  is  always  true. 

Fork  Rule 


Rule  Fork-1  shows  that  0  ii  p^  activates  P2.  Rule  Fork-2  shows  that  iiO activates  Pi.  Rule 
Fork-3  shows  that  if  Pi  activates  Pj  when  o  has  executed  a,  P^  II P^  activates  P^  II P^  when  o  has 
executed  a.  Rule  Fork-4  shows  that  if  P2  activates  P^  when  o  has  executed  a,  P^  II P^  activates 
P^  II P2  when  o  has  executed  a. 


Join  Rule 


Rule  Join-1  shows  that  011^7^2  activates  P^-,P .  Rule  Join-2  shows  that  7^11^0  activates 
/;;P.Rule7om-5  shows  that  if  P;  activates  p  when  o  has  executed  a,  p  lip  p  activates  p  Up  p 
when  o  has  executed  a.  Rule  Join-4  shows  that  if  P2  activates  p,  when  o  has  executed  a, 

p  lip  p  activates  p  lip  p  when  o  has  executed  a. 

Evolution  between  process  terms  can  be  described  with  Trace.  A  process  term  p  can  evolve, 
subjected  to  change  of  active  label  (o,a),  into  a  different  term  which  is  called  successor  of  p  and 

defined  as  Succ(p)  =  {  p  \  3(o,a) :  p — p  } .  If  a  term  p  evolve  into  another  term  p  ,  there  must 


be  a  sequence  of  active  labels  =  which  result  in 


P  >Pi  >P  ,  and  (o,a)  is  the  trace  of  term  p  evolving  into  term  p  .  The  trace 

is  used  to  describe  the  execution  sequence  of  executable  units  of  the  behavior  model. 

6.  A  Case  Study 

In  this  section,  we  give  a  simple  example  of  threat  air  defense  system  (TADS)  to  demonstrate 
the  availability  of  our  theory.  The  executable  model  of  TADS  is  built  using  the  meta  models  in 
section  3.  Due  to  limited  pages,  we  provide  only  a  fragment  of  the  behavioral  model  and  its 
algebra  semantics. 

There  are  four  operators  of  TADS:  Radar  Battalion  (RB),  Threat  Command  Center(TCC), 
Missile  Battalion(MB)  and  Anti-air  Gun  Battalion(AGB).  The  missile  interception  is  simulated  in 
following  way.  Once  the  RB  has  found  an  air  target,  the  information  will  be  sent  to  the  TCC  in 
time.  The  TCC  will  then  make  a  threat  assessment  on  it  and  decide  whether  they  have  to 
intercept  it  and  who  shall  undertake  the  task.  When  MB  or  AGB  have  accepted  the  interception 
order  and  the  target  information,  they  will  act  on  the  target,  and  at  the  same  time  collect  the  data 
of  interception  effect  and  send  them  back  to  TCC.  The  TCC  will  make  an  assessment  again  to 
decide  whether  it  is  a  successful  interception  or  they  have  to  arrange  another  interception.  The 
model  is  illustrated  in  Fig.  6.  The  formal  descriptions  of  the  executable  model,  according  to 


concrete  syntax  of  EBM  discussed  in  Section  4.1,  are  shown  in  Table  2. 


Table  2  The  formal  descriptions  of  the  TADS  behavioral  model 
activitymodel  Missileintercept; 
operator  RB 

action  DetectTarget  end  action 
end  operator 
operator  TCC 

action  AssessThreat  end  action 
end  operator 
operator  MB 

action  Intercept  end  action 
action  CollectDataOfEffect  end  action 
end  operator 
operator  AGB 

action  Intercept  end  action 
action  CollectDataOfEffect  end  action 
end  operator 
decision 

source  RB  DetectTarget  end  source 
FindAirTarget 

target  TCC  AssessThreat  end  target 
target  Over  end  target 
end  decision 
decision 

source  TCC  AssessThreat  end  source 
OrderMissile 

target  MB  Intercept  end  target 
target  Over  end  target 
end  decision 
decision 

source  TCC  AssessThreat  end  source 
OrderAnti-airGun 
target  AGB  Intercept  end  target 
target  Over  end  target 
end  decision 
transition 

source  MB  CollectDataOfEffect  end  source 
target  TCC  AssessThreat  end  target 
end  transition 
transition 

source  AGB  CollectDataOfEffect  end  source 
target  TCC  AssessThreat  end  target 


end  transition 
transition 

source  MB  Intercept  end  source 
target  MB  CollectDataOfEffect  end  target 
end  transition 
transition 

source  AGB  Intercept  end  source 
target  AGB  CollectDataOfEffect  end  target 
end  transition 
end  activitymodel 

Applying  the  transformation  algorithm  in  Section  4.2,  the  EAA  process  terms  of  TADS  activity 
model  can  be  automatically  generated  and  is  listed  as  follows. 

Pi  =  {RB,  DetectTarget).P2 

Pi  —  P3  '^FindAriTarget  0 

P3  =  (TCC,  AssessThreat).P4 

P4  —  P 5  OrderMissile  P 6 

P6  —  P?  Order Anti-3.irG\m  0 

Ej  =  (MB,  Intercept). P 8 

Pg  =  {MB,  CollectDataOfEffect). P 3 

Pj  =  (AGB,  Intercept). P 9 

P9  =  (AGB,  CollectDataOfEffect). P 3 

The  set  of  label  is  A=  {{RB,  DetectTarget),  EindAirTarget,  Nothing,  {TCC,  AssessThreat), 
OrderMissile,  {MB,  Intercept),  {MB,  CollectDataOfEffect),  InterceptSuccessfully, 
Order Anti-airGun,  {AGB,  Intercept),  {AGB,  CollectDataOfEffect) } . 

To  verify  the  activity  model,  let  us  check  two  label  sets. 

L]  =  {{RB,  DetectTarget),  EindAirTarget,  {TCC,  AssessThreat),  OrderMissile,  {MB,  Intercept), 
{MB,  CollectDataOfEffect),  InterceptSuccessfully). 

Li  =  {{RB,  DetectTarget),  EindAirTarget,  {TCC,  AssessThreat),  OrderAnti-airGun,  {AGB, 
Intercept),  {AGB,  CollectDataOfEffect),  InterceptSuccessfully). 

For  Li,  we  can  observe  the  evolution  trace  of  {Pi,  P2,  P3,  P4,  P5,  Pg,  Psfi).  And  for  L2,  we  can 
observe  the  evolution  trace  of  {Pi,  P2,  P3,  P4,  P6,  P7,  P9,  Psfi)-  The  two  traces  are  all  valid,  for 
they  all  end  by  0  which  means  the  End  of  activity  model.  The  above  process  traces  show  that  the 
air  target  is  intercepted  by  either  MB  or  AGB. 

7.  Conclusions 

The  behavioral  models  of  SoS  architecture  are  usually  built  with  UML  activity  diagram.  Due 
to  poor  formalization  of  UML,  these  models  are  not  executable,  which  brings  inconveniency 
during  evaluation  of  SoS  architecture.  The  paper  suggests  a  new  approach  of  executable 
modeling  and  simulation.  The  main  contributions  are  summarized  as  follows: 

(1)  The  meta  models  for  both  structures  and  behaviors  of  SoS  are  presented  by  extending 
fUML  meta  models.  With  these  meta  models,  the  engineers  may  accurately  describe  SoS 


architecture  and  build  UML  models. 

(2)  The  concrete  syntax  and  algebra  semantics  of  executable  models  are  discussed  in  details. 
And  a  number  of  semantic  functions  are  introduced  for  mapping  of  the  syntax  descriptions 
of  behavioral  models  into  items  of  executable  activity  algebras. 

(3)  Executable  rules  are  defined.  With  these  rules,  the  process  terms  which  simulate  the 
behaviors  of  SoS  can  evolve  as  process  traces,  which  make  model  analysis  and  validation 
easier. 

However,  our  work  is  just  in  beginning.  We  are  challenged  by  dealing  with  existing  products 

of  behavioral  models,  some  of  them  being  built  in  other  paradigms  such  as  UML  sequence 

diagram  and  IDEE  3.  The  future  research  will  be  on  extending  the  meta  models  to  make  our 

approach  to  be  compatible  with  other  modeling  paradigms. 
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